Based on #1477

Reason

Today, we can only test the RxPlayer's DRM-related logic either through:

• unit tests. Writing those are very time-consuming considering that EME-related code changes often, and thus often lead to unit test rewrites.

  To lower the lost time, we added the concept of "global unit tests", which instead of performing tests at the lower function-level, it performed them at the module-level, which has its own API much less subject to change.

  Even then, we would prefer more stable and representative tests.

• rx-tester: Our closed-source repository that tests real production contents through one of our main application at canal+.

  This is nice but we have to go through another application that do not use the API at its full extent, so it's not an exhaustive test for us.
  It's also closed-source and relying on specific real-life contents where we would prefer the idea of directly running in the RxPlayer CI tests on contents with all kinds of quirks.

• manually, which is also time-consuming.

The idea is here to actually run DRM-related integration tests by completely mocking in them:

• EME API
• MSE API
• HTML5 video API

To be able to run those tests through npm run test:integration either locally or in our CI.

Implementation

I decided to add an [incomplete] in-JS HTML5 media element implementation as an "experimental tool" (in src/experimental/tools/DummyMediaElement).

That fake HTMLMediaElement actually implements the IMediaElement type defined in #1397 and so should be compatible with what the RxPlayer expects of a media element.

It has also those supplementary properties:

• FORCED_MEDIA_SOURCE: our implementation of a IMediaSource / ISourceBuffer etc. (as defined in [Proposal] Forbid usage of the HTMLMediaElement and MSE TS types #1397) for a MSE implementation
• FORCED_EME_API: our implementation of IMediaKeySystemAccess, IMediaKeys, IMediaKeySession etc. (as defined in [Proposal] Forbid usage of the MediaKeys type and other EME TS types #1477) for an EME implementation

When those are present, the RxPlayer will rely on them instead of the usual MSE and EME implementations.

I also added:

• In the demo page: I added a Dummy Media API switch allowing to rely on our MSE+EME+HTML5 implementation instead of the browser's. This is mainly to be able to debug the RxPlayer logic on contents that cannot normally be played on the demo page, usually because of DRM.

  

  With this on, those contents will load - even if with a black screen (though subtitles are displayed) - and the RxPlayer will believe that the content can play.

• In integration tests: I added a fake encrypted content with several keys and some tests checking for errors thrown, fallbacks, license request configuration etc.. More tests should be quick to add.

  On that matter, I already spotted a potential issue when the getLicense respond much faster than a SourceBuffer.prototype.appendBuffer call. I removed that test as I try to fix the issue.

What's missing

Not the full extent of the MSE, EME nor HTML5 media API is implemented here.

Most notably, I did not yet implement:

• actual content playback, as in the loaded content will always stay in pause.

  The fake implementation will block actual playback by relying on the NotAllowedError exception on each play call, so the RxPlayer still understands the issue.

  I did not implement playback yet because I did not want to take time implementing time-related complexities (stalling, ending etc.). Though I plan to.

• persistent licenses. This does not seem hard to do, but I did not take the time yet. My implementation will just gives the standard answer indicating that the feature is not supported

• MSE "sequence" mode: this can become complex and we do not need it at all for now in the RxPlayer

• Only "mp4" files are handled for now, as we have to do some container parsing here

• Multiple other minor features